Most paperless work-instruction rollouts go reasonably well. Operators learn the tablet, the routing logic gets debugged, and within a few weeks nobody misses the laminated traveler sheets. Then someone asks the harder question: what happens to scrap tracking and first-pass yield when the paper goes away? That’s usually where the project stalls, because FPY and scrap data aren’t just a UI change — they’re a reporting continuity problem. Whoever owns the quality dashboard needs next month’s numbers to mean the same thing as last year’s, and that’s a much harder thing to guarantee than “operators can find the right screen.”
This is the part of the migration nobody budgets enough time for, and it’s where cutover week either goes smoothly or generates a data gap that shows up in a QBR eighteen months later when someone tries to pull a three-year trend and finds a hole in the middle of it.
Why FPY and scrap are a different animal than work instructions
Work instructions are prescriptive — you’re just replacing a document with a digital one. Scrap and FPY data is diagnostic. It feeds Pareto charts, supplier scorecards, containment decisions, and often ties into corrective action systems under your quality management system. If the reason codes shift meaning even slightly during cutover, you don’t just get a UI hiccup — you get a broken trend line that quality engineers will quietly stop trusting, which defeats the entire point of moving to MES-driven data collection in the first place.
The other wrinkle is genealogy. Paper travelers, for all their flaws, are forgiving — a supervisor can scribble a scrap quantity against a lot number after the fact and nobody loses sleep. MES systems that tie scrap events to serialized units, work orders, or lot genealogy are far less forgiving of a missed transaction. If cutover goes cold in the middle of a shift, you can end up with units that exist in the ERP system, exist physically on the floor, but have no clean digital scrap or pass record — a genealogy gap that’s expensive to reconstruct and sometimes impossible.
Step 1: Map your paper reason codes before you touch the MES config screen
Before configuring anything, pull every paper traveler scrap code and rework disposition code your plant has used over a meaningful trailing period — ideally a year or more, so you capture seasonal defect patterns. You’ll almost always find the same problems:
- Codes that were technically retired but still show up because operators default to familiar handwriting.
- Free-text “other” fields that quietly account for a large share of volume because the formal code list never kept up with actual failure modes.
- Near-duplicate codes created by different shifts or different supervisors who never reconciled their lists.
Build a crosswalk spreadsheet: paper code, description, frequency, proposed MES code. This is tedious and nobody enjoys it, but it’s the single highest-leverage activity in the entire migration. Skipping it is how you end up with a beautiful new MES reason-code taxonomy that can’t be reconciled against three years of historical Pareto data.
Don’t let engineering “improve” the taxonomy mid-migration
Cutover week is not the time for quality engineering to finally build the perfect, granular root-cause taxonomy they’ve wanted for years. Every new code you introduce that doesn’t map cleanly to a historical paper code is a discontinuity in your trend line. If the taxonomy genuinely needs an overhaul, do it as a separate, planned initiative with its own before/after baseline — not bundled into the paper-to-digital cutover.
Step 2: Define your FPY capture points on the actual value stream, not the org chart
First-pass yield only means something if your capture points are defined at process steps that reflect where quality risk actually shows up — typically after operations with real defect opportunity (forming, machining, assembly, test), not after every single scan-in/scan-out station just because the MES makes it easy to add one.
A common mistake: MES implementers add FPY checkpoints at every station because the system supports it, which inflates the denominator and makes yield numbers incomparable to the paper-era baseline, where FPY was probably only ever calculated at final test or a handful of inspection gates. Match your new capture points to where paper FPY was historically measured first. You can always add finer-grained station-level yield later as a separate metric — just don’t let it contaminate the FPY number people have been trending for years.
Step 3: Pick a cutover pattern — and pick deliberately
There are really only two viable approaches, and the failure mode is different for each.
Cold cutover (paper stops, MES starts, same shift)
This is clean if it works, and a genealogy nightmare if it doesn’t. The classic failure: a shift starts on paper, a supervisor decides midday to “just switch over,” and units in process at that moment end up with incomplete travel history — some operations recorded on paper, some in MES, with no reconciliation. If you cold-cutover, do it at a shift boundary, never mid-shift, and only for work orders that haven’t started an operation sequence yet. Anything already in process finishes its full router on paper.
Parallel run (paper and MES both recorded for a defined window)
Safer for genealogy, but it has its own well-known failure mode: dual systems run two weeks longer than planned because “we’re not quite confident yet,” operators get fatigued double-entering scrap dispositions, and data quality on both sides degrades — operators start rushing the paper because they know it’s the throwaway copy. If you run parallel, set a hard end date before you start, publish it, and treat it as a fixed constraint, not a soft target. A parallel run with no expiration date isn’t a safety net, it’s a second production system you now have to maintain.
Step 4: Validate before you trust the new numbers
Before declaring cutover complete, run a reconciliation pass:
- Pull scrap volume by reason code from MES for the first full week and compare the code mix — not just total scrap quantity — against the same period a year prior. Wildly different code distribution is a signal the crosswalk mapping is wrong, not that behavior suddenly changed.
- Spot-check a sample of physical scrap tags or NCR paperwork against MES transactions to confirm reason codes are actually being selected correctly, not defaulted to whatever’s first in the dropdown.
- Check for orphaned units — anything with a work order status that doesn’t match a completed genealogy record. This is your genealogy-gap early warning.
- Confirm FPY denominators (units started) reconcile against ERP-reported production quantities for the same period.
What “done right” looks like
A clean cutover means a quality engineer can pull a twelve-month Pareto chart that spans the paper-to-MES transition without a visible seam — same top defect categories, same rough proportions, no mystery spike in “other.” It means no shift boundary where units simply vanish from genealogy. And it means operators trust the reason-code list enough to pick the accurate one instead of the fast one, which is really the whole point of leaving paper behind in the first place.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
